約 2,855,462 件
https://w.atwiki.jp/bambooflow/pages/117.html
SysmtemC関連の用語集 高位設計という分野でいろいろ用語があって混乱するので、簡単にめも。 間違いがあるかも。 SysmtemC関連の用語集一般的な用語BCA CAモデル CC ESL設計 GreenSocs OCP-IP OCP/TL0 OCP/TL1 OCP/TL2 OCP/TL3 OSCI OSCI TLM PV PVT RTL SystemC TFモデル TLM UTFモデル 高位合成 高位設計 サイクルベース システムレベル設計 動作合成 トランザクション(transaction) 一般的な用語 SystemCにかぎらず。 BCA 抽象度レベルの1つ。 機能ブロック間を流れる(バス)データのタイミングを正確にとらえたモデル。 バスのタイミング精度は高い。 バスはRTLに近い記述、機能ブロックはタイミングを持たなくてもよい。 BCA：Bus Cycle-Accurrate、バスサイクルアキュレート 抽象レベルの順番は高い順に、UTF、TF、BCA、CA CAモデル 抽象度レベルの1つ。 CA：Cycle-Accurate、サイクルアキュレート 機能ブロック内の詳細な動作を記述する。 タイミング精度は高い。 RTL記述もしくはそれに近いモデル。 抽象レベルの順番は高い順に、UTF、TF、BCA、CA CC CC：Cycle Callable CA、BCAをあわせて呼ぶことがある。 ESL設計 RTL設計よりも抽象度の高い工程を広く指す用語。 ESL：Electronic System Level 高位設計をESL設計と呼び方を置き換えることが多い。 GreenSocs TLM標準化を推進している団体の1つ。 抽象レベルを定義し、OSCIの基本APIをベースにそれらの抽象レベルのAPIを定義している。 残念ながらその定義は少しずつ異なっている。 OCP-IP TLM標準化を推進している団体の1つ。 OCP-IP OCP International Partnership Association, Inc. OCP Open Core Protocol OCPは、完全に支援されたオープンライセンス方式の総合的なインターフェイスソケット。 OCP/TL0 OCP-IPが提唱する抽象レベルの1つ。 RTL Layer。 OCP/TL1 OCP-IPが提唱する抽象レベルの1つ。 transfer layer (closest to implementation) CA(CC)にあたる。 OCP/TL2 OCP-IPが提唱する抽象レベルの1つ。 transaction layer TF(+BCA)にあたる。 OCP/TL3 OCP-IPが提唱する抽象レベルの1つ。 message layer (highest and most abstract level) UTFにあたる。 OSCI SystemCの標準化・普及推進団体。 オスキーと読む。 OSCI Open SystemC Initiative OSCIサイトからSystemCライブラリが無償でダウンロードできる。 OSCI TLM OSCI TLM WGが開発した、SystemCを用いてTLMを実現するためのライブラリ。 各種通信APIや通信インタフェースなどが定義されている。 OSCIサイトから、TLM-1.0、TLM-2.0 Draft1、TLM-2.0 Draft2がリリースされている。 PV OSCI、GreenSocsが提唱する抽象レベルの1つ。 PV：Programmer s View ソフトウェアを書く人側からみた、充分な精度という意味。 UTF を PV と呼ぶこともある。 PVT OSCI、GreenSocsが提唱する抽象レベルの1つ。 PVT：Programmer s View Timing PVに時刻の情報を加えたもので、時間精度が上がる。 TFと同じ意味。 RTL RTL：Register Transfer Level レジスタ間のデータ転送と演算によって記述。 設計言語としてVerilogHDLやVHDLなどが広く使わる。 SystemC OSCIにより企画されたハードウェアモデリング言語。 C++だけで構成されている。 IEEE1666で標準化されている。 TFモデル 抽象度レベルの１つ。 TF：Timed Function、タイムド・ファンクション 抽象レベルの順番は高い順に、UTF、TF、BCA、CA TLM TLM：Transaction Level Modeling、トランザクション・レベル・モデリング モデルの動作をトランザクション(1つの処理)を基準に設計する手法のこと。 SystemC記述のモデルを全般にTLMという用語を使うことが多い。(間違った使い方をしたりするが) sc_fifo等のメソッド呼び出し仕様はTLMといえる。 抽象度については、まだ統一性がみられないため混乱しやすい。 UTFモデル 抽象度レベルの1つ。 UTF：Untimed Function、アンタイムド・ファンクション 抽象レベルの順番は高い順に、UTF、TF、BCA、CA 高位合成 RTLよりも高い抽象レベルモデルから、ハードウェア記述に変換すること。 Cコード→RTL SystemC(TLM)→RTL SystemC(BCA)→RTL ASICをターゲットとする場合、除算とか含まれているときは一気にゲートレベルまで落とすものもある。 いくつかの高位合成ツールがでている。 有名どころは、 Forte：Cynthesizer MentorGraphics：Catapult NEC CyberWorkBench(CWB) 高位設計 ハードウェア設計に入るまでの上位工程をさす。 RTL設計よりも上位工程としては、システム設計、モデリング検討、モデル設計、モデル記述等がある。 SystemCではモデル設計、モデル記述を検討することができる。 サイクルベース クロックサイクル単位で処理を行う方式。 システムレベル設計 高位合成技術、協調設計技術を総合して呼ぶ。 ハードウェアとソフトウェアとを区別なく、ソフトウェアの記述と同等の抽象度でデジタルシステム全体を記述すること。 動作合成 高位合成と同じ意味。 トランザクション(transaction) 処理の単位、集まり。 具体的な例をあげると、イニシエータとターゲット間でバスを介してデータ受け渡しをするとき、インターフェースの関数コールにて1つの構造体(のポインタ)を受け渡して処理動作をさせる。この関数コールによる構造体の受け渡しをさす。
https://w.atwiki.jp/bambooflow/pages/161.html
SCV(SystemC Verification Standard) SCVとは モニタとレコーディング ランダム生成 参考 http //www.asic-world.com/systemc/verification.html
https://w.atwiki.jp/bambooflow/pages/116.html
SystemCのエラボレーション・フェーズ SystemCのエラボレーション・フェーズ説明 実験 説明 エラボレーション・フェーズは、シミュレーション開始前のフェーズ。 ここでは、つぎの作業をしている データ構造の初期化 接続関係の構築もし、sc_in 、sc_out 等が接続されていない場合エラーを出力する 次の実行フェーズの前処理(end_of_elaboration) SystemCでは3つのフェーズが存在する。 エラボレーション・フェーズ 実行フェーズ クリーンアップ・フェーズ sc_start()が実行されると、まずエラボレーション・フェーズにはいる。 シミュレーションは実行フェーズである。 sc_start()から抜けるとクリーンアップ・フェーズにはいる。 sc_moduleには、次の4つのvirtual関数が存在する。 before_end_of_elaboration end_of_elaboration start_of_simulation end_of_simulation どのような順番で呼ばれるのか気になったので実験してみた。 実験 main.cpp #include systemc.h #include "mod.h" int sc_main( int argc, char* argv[] ) { MOD *mod; printf("main begin\n"); mod = new MOD( "mod" ); printf( "main exec sc_start\n" ); sc_start( -1 ); printf( "main end\n" ); return 0; } MOD.h #ifndef __MOD_H #define __MOD_H #include systemc.h SC_MODULE( MOD ) { SC_CTOR( MOD ) { printf( "mod constructor\n" ); SC_THREAD( thread_proc ); } ~MOD() { printf( "mod destructor\n" ); } void thread_proc() { printf( "mod exec sc_stop\n" ); sc_stop(); } void before_end_of_elaboration() { printf( "mod before_end_of_elaboration\n" ); } void end_of_elaboration() { printf( "mod end_of_elaboration\n" ); } void start_of_simulation() { printf( "mod start_of_simulation\n" ); } void end_of_simulation() { printf( "mod end_of_simulation\n" ); } }; #endif /* __MOD_H */ 実行結果 main begin mod consructor main exec sc_start mod before_end_of_elaboration mod end_of_elaboration mod start_of_simulation mod exec sc_stop SystemC simulation stopped by user. mod end_of_simulation main end sc_startが実行されると before_end_of_elaboration() エラボレーション実行 end_of_elaboration() start_of_simulation() シミュレーション開始 という順番で関数が呼ばれる。 sc_stopが実行されると end_of_simulation が実行され、sc_start()内の無限ループから抜けてsc_mainへ戻る。
https://w.atwiki.jp/bambooflow/pages/128.html
SystemC プロセスについて SystemC プロセスについてプロセスとは プロセスの種類SC_METHOD SC_THREAD SC_CTHREAD プロセスとは プロセスはプログラムが並列動作するための機構の1つ。 シミュレーションが開始されると、プロセスとして指定された関数(プロセス関数)が実行される。 プロセス関数は1つのモジュールに複数存在することも許される。 ソフトウェアの場合、プログラムは上から順に逐次実行の動作となるが、ハードウェアの場合には並列動作となるため、ピュアなCやC++ではハードウェアを表現するには難がある。並列動作を可能賭したのがSystemCであり、プロセスはSystemCの特徴の1つとなっている。 プロセスは、Verilog-HDLでいうところのinitial文やalways文に該当する。 プロセスの種類 次の3つが存在する。 SC_METHOD SC_THREAD SC_CTHREAD それぞれマクロとなっているが、詳しい説明はしない。 SC_METHOD Verilog-HDLのalways文に似ている。 センシティビティ・リストの記述が必要。 シミュレーション中、何度でも呼び出される。 プロセス内にwait記述することはできない。 プロセス内に無限ループを構成してはならない。 このプロセスでは機能記述することは少ない。 RTL記述の表現に使用したり、信号の受渡しのタイミング調整に使う程度。 構文 void process_func(); // 戻り値はvoid、引数もvoid、もしくは記述しない SC_METHOD( process_func ); RTL組合せ回路記述例 SC_MODULE( MOD ) { sc_in sc_uint 8 in_a; sc_in sc_uint 8 in_b; sc_out sc_uint 9 out; SC_CTOR( MOD ) { SC_METHOD( adder_method ); sensitive in_a in_b; } void adder_method() { out.write( in_a.read() + in_b.read() ); } RTLのF/F回路生成 sc_in_clk Clk; sc_in bool ResetN; sc_in sc_uint 8 a; sc_in sc_uint 8 b; sc_in sc_uint 8 z; SC_CTOR( MOD ) { SC_METHOD( method0 ); sensitive Clk.pos() ResetN.neg(); } void method0() { if (!ResetN.read()) { z.write( 0 ); // リセット記述 } else { z.write( a.read() + b.read() ); } } SC_THREAD Verilog-HDLのinitial文に似ている。 シミュレーション開始時の1度だけ呼び出される。プロセスの実行が終了してしまうと再度呼ばれることはないため、通常はwhile(true){}を使って無限ループを構成してその中に機能記述する。 センシティビティ・リストの記述が可能。センシティビティ・リストはなくてもよい。 このプロセスを使用して機能記述することが多い。 3つのプロセスの中で、もっともアルゴリズムを記述するのに敵している。 構文 void process_func(); // 戻り値はvoid、引数もvoid、もしくは記述しない SC_THREAD( process_func ); 記述例 SC_CTOR( ) { SC_THREAD( main_thread ); } void main_thread() { while (true) { // ここに機能を記述 wait( event ); } } SC_CTHREAD SC_THREADに似ているが、クロック動作の記述専用のTHREADである。 センシティビティ・リストは持たない。 wait記述はクロック・イベントを待つ動作となる。 reset_signal_isによりリセット動作が記述可能。 SC_THREADに比べてシミュレーション速度が遅くなる。 構文 sc_in_clk CLK; // クロック信号(sc_clockとつなぐ) void process_func(); // 戻り値はvoid、引数もvoid、もしくは記述しない SC_CTHREAD( process_func, clk.pos() ); 記述例 sc_in_clk CLK; sc_in bool RESET_N; SC_CTOR( ) { SC_CTHREAD( main_thread, CLK.pos() ); reset_signal_is( RESET_N, false ); } void main_thread() { // ここにリセット動作を書く wait(); while (true) { // ここに機能を記述 wait(); } }
https://w.atwiki.jp/bambooflow/pages/111.html
SystemCの基本データタイプ SystemCの基本データタイプ基本データタイプ一覧 キャスト(データタイプの変換) 変換一覧(to_xxx)to_stringの使い方 coutで表示させたい場合 printfで表示させたい場合 sc_stringがない？ SystemCでは、標準C++のデータ型に加えて以下のようなデータ型が扱える。 基本データタイプ一覧 データタイプ 符号 説明 使用例 sc_int＜W＞ 付 Wビット整数 sc_int 16 a = -123; sc_uint＜W＞ 無 sc_uint 32 addr = 0xdeadbeaf; sc_bigint＜W＞ 付 Wが64ビット以上の整数 sc_biguint＜W＞ 無 sc_bit - 0 , 1 の2値 sc_bit b = 1 ; sc_logic - 0 , 1 , x , z の4値 sc_bit l = x ; sc_bv＜W＞ - sc_bitのWビットベクタ sc_bv 8 bv = "10110110"; sc_lv＜W＞ - sc_logicのWビットベクタ sc_lv 8 lv = "xxxx1010"; sc_fixed＜NW, NI＞ 付 固定小数点NW=全サイズ、NI=整数サイズ sc_fixed 8,4 f = -1.25; sc_ufixed＜NW, NI＞ 無 sc_ufixed 8,4 f = 1.5; 他にもあるが、基本はこんなもの。 C++では、8、16、32、64といったサイズしか扱うことはできない。 SystemCではハードウェアを意識した記述も書けるようにビットサイズが可変であるデータ型が準備されている。 また、sc_logic、sc_lv といった4値を扱うことができるデータ型もある。ただし4値を扱うとシミュレーション速度は低速になる。 SystemCの主な利用価値は、ソフトウェアとの強調検証となっている。そのため、速度が低下する4値は扱うことはほとんどない。 高位合成でも、4値は使用せずにsc_int 、sc_uint がほとんどになる。 sc_fixed ,sc_fixed の高速版であるsc_fixed_fast ,sc_ufixed_fast もある。 キャスト(データタイプの変換) sc_uint 16 x; sc_int 32 y; y = (sc_uint 32 )x; // C++のキャストと同じ 変換一覧(to_xxx) 基本データタイプに共通。 戻り値 関数 int to_int() unsigned int to_uint() long to_long() unsigned long to_ulong() int64 to_int64() uint64 to_uint64() double to_double() const std string to_string() to_stringの使い方 書式 const std string to_string (sc_numrep numrep) const sc_numrep列挙 説明 例(sc_int 8 100) 例(sc_int 8 -100) SC_NOBASE = 0 そのまま "100" "-100" SC_BIN = 2 2進数 "0b01100100" "0b10011100" SC_OCT = 8 8進数 "0o144" "0o634" SC_DEC = 10 10進数 "100" "-100" SC_HEX = 16 16進数 "0x64" "0x9c" SC_BIN_US 2進数(2の補数) "0bus1100100" "negative" SC_BIN_SM 符号付2進数 "0bsm01100100" "-0bsm01100100" SC_OCT_US 8進数(2の補数) "0ous144" "negative" SC_OCT_SM 符号付8進数 "0osm144" "-0osm144" SC_HEX_US 16進数(2の補数) "0xus64" "negative" SC_HEX_SM 符号付16進数 "0xsm64" "-0xsm64" SC_CSD 正規化符号付数字 "0csd10-00100" "0csd-0100-00" coutで表示させたい場合 2進数で代入したい場合。 普通Cでは、2進数は表示できないがSystemCならば表示できたりする。 sc_int 8 data = "0b01010011"; cout "data = " data.to_string(SC_HEX) endl; "0b"の後に"0"を付けると正数、"1"を付けると負数となる。 sc_int 8 data = 100; cout data endl; // 通常表示 cout data.to_string( SC_HEX ) endl; // 16進数 printfで表示させたい場合 SystemCのデータ型を表示するときの方法。 sc_int 32 data; printf( "data = %d\n", (int)data ); // キャスト printf( "data = %d\n", data.to_int() ); // int型に変換 次の方法はダメ。 printf( "data = %d\n", data ); // セグメンテーションエラー 以下のような警告が出る。 test.cpp function 内の `int sc_main(int, char**) test.cpp 9 警告 cannot pass objects of non-POD type `class sc_dt sc_int 32 through `... ; call will abort at runtime ただし、コンパイルは通る。 通るが、実行すると"セグメンテーションエラー"となる。 sc_stringがない？ SystemCのバージョン2.2ではsc_stringがなくなっている。 とりあえず、以下のようにすればよいかも。 typedef sc_string std string;
https://w.atwiki.jp/bambooflow/pages/170.html
SystemCでユーザデータタイプを使うユーザデータタイプを使うときの問題 ユーザデータタイプを使うための解決 bool operator==()はなぜ必要？ テンプレートを使用したユーザデータタイプの場合 SystemCでユーザデータタイプを使う sc_signal やsc_buffer を介したデータやりとりは、既に定義されたbool,int,sc_int 等は問題なく使うことができます。 しかし、ユーザが独自に構造体を定義して、それを受渡しする場合問題が生じる。 ここでは、sc_signal もしくはsc_buffer でユーザデータタイプを使用する方法をメモします。 ユーザデータタイプを使うときの問題 次のコードを見てください。 struct StrData { bool valid; int data; }; int sc_main( int, char** ) { sc_signal StrData sig; } 上記をコンパイルしようとすると、次のようなエラーが発生します。 /usr/local/systemc-2.2.0/include/sysc/communication/sc_signal.h In member function ‘void sc_core sc_signal IF write(const T ) [with T = StrData]’ main.cpp 119 instantiated from here /usr/local/systemc-2.2.0/include/sysc/communication/sc_signal.h 221 error no match for ‘operator==’ in ‘((sc_core sc_signal StrData *)this)- sc_core sc_signal StrData m_new_val == ((sc_core sc_signal StrData *)this)- sc_core sc_signal StrData m_cur_val’ ・・・ ・・・ はじめなんじゃこりゃってなりますが、‘operator==’がどうやら足りないというメッセージのようです。 なにか工夫をしないといけないようです。 ユーザデータタイプを使うための解決 ユーザデータタイプをsc_signal＜＞やsc_buffer＜＞で使う場合は、次の３つを定義してあげます。 bool operator==() sc_trace() ostream operator () 具体的には、次のように修正します。 struct StrData { bool valid; int data; // sc_signal で使う bool operator==(const StrData other) const { return ( (valid == other.valid) (data == other.data) ); } }; // トレース時使用する void sc_trace( sc_trace_file* tf, const StrData trans, std string name ) { sc_trace( tf, trans.valid, name + ".valid" ); sc_trace( tf, trans.data, name + ".data" ); } // SystemCで使う ostream operator ( ostream os, const StrData trans ) { os "(" trans.valid ", " trans.data ")"; return os; } int sc_main( int, char** ) { sc_signal StrData sig; } 構造体１つを扱うのにこれだけ定義が増えるのはちょっと面倒臭いですが、これもSystemCの仕様なのでしかたないです。 ここで、operator==はちゃんと書かないとダメですが、sc_trace()とoperator ()の関数の中身は、ないと不便なだけで書かなくてもコンパイルできます。 面倒臭いときは、わたしは省略しちゃいます。 bool operator==()はなぜ必要？ 次のコードを見てください。 SC_MODULE(MOD) { sc_in StrData din; SC_CTOR(MOD) { SC_METHOD( method ); sensitive din; // dinが変化したとき } void method() { std cout "din = " din.read() std endl; } }; メソッドであるmethod()がよばれるのは、sensitive dinよりdinが変化したときであるとわかります。 「変化した」というのをSystemCではどうやって判断しているかというと内部で"=="で比較しています。なので"=="で比較できるというのが前提でSystemCが設計されているので、ないとコンパイル時に"operator==が無い"と怒られるわけです。 SystemCデータタイプであるsc_int やsc_fixed はちゃんとoperator==が定義されているので、そんなことは気にしなくても使えます。 テンプレートを使用したユーザデータタイプの場合 次のようなテンプレートを使ったデータタイプを見てみます。 template typename DT, int N struct Payload { bool w_flag; int address; DT data[N]; }; 次のように修正します。 template typename DT, int N struct Payload { bool w_flag; int address; DT data[N]; // sc_signal で必要 template typename ODT,int ON bool operator==( const Payload ODT,ON other) const { bool ret; ret = (w_flag == other.w_flag) (address == other.address); for (int i=0; i N; i++) ret = ret (data[i] == other.data[i]); return ret; } }; // トレースで必要 template typename DT, int N void sc_trace( sc_trace_file* tf, const Payload DT,N trans, std string name ) { sc_trace( tf, trans.w_flag, name + ".w_flag" ); sc_trace( tf, trans.address, name + ".address" ); for (int i=0; i N; i++) { std ostringstream oss; oss name ".data_" i; sc_trace( tf, trans.address, oss.str() ); } } // SystemCで必要 template typename DT, int N ostream operator ( ostream os, const Payload DT,N trans ) { os "(" trans.w_flag ", " trans.address ", "; for (int i=0; i N; i++) os (int)trans.data[i] ", "; os ")"; return os; }
https://w.atwiki.jp/bambooflow/pages/66.html
リセット動作 SystemC v2.1では、リセット動作を記述できるプロセスは、SC_METHODとSC_CTHREADだけ。 SC_THREADでのリセット動作の実現はやってやれないこともないと思うが、現状難しいと思う。 でも、のちのちのヴァージョンではSC_CTHREADは廃止されてSC_THREADでリセット動作も可能になるかも。 SC_METHODでのリセット動作 カウンタ クロック数をカウントする。 入力はクロック信号、リセット信号で、出力はカウンタ数である。 入力reset_xがfalseのとき、内部カウンタctrは0にクリアされる。 入力reset_xがtrueのとき、内部カウンタはクロックの立ち上がりでインクリメントされる。 #include systemc.h SC_MODULE(COUNTER) { sc_in_clk clk; sc_in bool reset_x; sc_out int ctr; void process() { if (!reset_x) { ctr = 0; } else { ctr++; } } SC_CTOR(COUNTER) { SC_METHOD(process); sensitive clk.pos(); } };
https://w.atwiki.jp/bambooflow/pages/119.html
チャネル チャネルチャネルとは プリミティブチャネルsc_prim_channelについて 用意されているプリミティブチャネル一覧 チャネルとポートの接続対応表 sc_signalとsc_bufferの違いは？ sc_clockは何チャネル？ 階層チャネルsc_channelについて まとめ チャネルとは SystemCは、モジュール間の信号通信に"チャネル"という概念を提供して接続する機構を持たせている。 チャネルとモジュール間は、インターフェースとポートを介して接続する。 チャネルはインターフェースを実装(継承)する。モジュール側がそのインターフェースを持ったポートによりチャネルにアクセスすることができる。 Verilogだとwireで信号を接続するが、チャネルはwireのように単純な接続から内部に調停するような機構を持たせた複雑なものも表現できる。 チャネルはSystemCライブラリにいくつか用意されているが、ユーザが各自設計することができる。 チャネルには大きく分けて2種類ある。 プリミティブチャネル(primitive channel) 階層チャネル(hierarchical channel) プリミティブチャネルと階層チャネルの違いは、チャネル内にプロセスを持っているか持っていないかである。 プロセスを持っていないチャネルが、プリミティブチャネルで、 プロセスを持っているチャネルが、階層チャネルである。 プリミティブチャネル sc_prim_channelについて プリミティブチャネルはsc_prim_channelを継承している。 ユーザがプリミティブチャネルを作ることはまずない。 用意されているプリミティブチャネル一覧 sc_signal＜type＞ 信号(プロセス間、子モジュール間との通信用) sc_buffer＜type＞ sc_signalと同じ、値の書き込み時必ずイベント発生 sc_fifo＜type＞ FIFOバッファつき入出力チャネル(使い方) sc_signal_resolved 1ビット幅の解決済み信号 sc_signal_rv＜W＞ ビット幅Wをもつ解決済み信号 sc_semaphore 排他制御チャネル sc_mutex チャネルとポートの接続対応表 チャネルとポートの接続対応は次のとおり。 入力側 チャネル 出力側 sc_port sc_signal_in_if X sc_signal X sc_buffer X sc_port sc_signal_out_if X sc_port sc_signal_inout_if X sc_port sc_signal_inout_if X sc_in X sc_out X sc_inout X sc_inout X sc_in bool sc_clock sc_in_resolved sc_signal_resolved sc_out_resolved sc_inout_resolved sc_inout_resolved sc_in_rv W sc_signal_rv W sc_out_rv W sc_inout_rv W sc_inout_rv W sc_port sc_fifo_in_if X sc_fifo X sc_port sc_fifo_out_if X sc_fifo_in X sc_fifo_out X X 型(bool,unsigned char,int,sc_uint , sc_int , etc.) W ビット幅(int型) アクセス側 チャネル sc_port sc_mutex_if sc_mutex sc_port sc_semaphore_if sc_semaphore sc_signalとsc_bufferの違いは？ sc_signalとsc_bufferの違いは、値が変化する/しないに関係なく書き込み時に毎回イベントが発生するか/しないかである。 値が変化したときのみイベントが発生するのは、sc_signal 値を書き込み時毎回イベントが発生するのは、sc_buffer 例 sc_signal int sig_data; sc_buffer int buf_data; //初期値はどちらも"0"とする。 for (int i=0; i 10; i++) { sig_data.write( 1 ); // sc_signalに10回"1"を書き込む buf_data.write( 1 ); // sc_bufferに10回"1"を書き込む } //////////////////////////////////////// sc_in int sig_data; sc_in int buf_data; int cntr1; int cntr2; SC_CTOR( MOD ) cntr1(0), cntr2(0) // カウンタの初期値を"0"にする { SC_METHOD( proc1 ); sensitive sig_data; // sc_signal SC_METHOD( proc2 ); sensitive buf_data; // sc_buffer } void proc1() { ++cntr1; printf( "cntr1 = %d\n", cntr1 ); // sc_signal } void proc2() { ++cntr2; printf( "cntr2 = %d\n", cntr2 ); // sc_buffer } 2つの信号(sig_data, buf_data)に毎回"1"を書き込んだとき、 sc_signalははじめの書き込み時の1回だけイベントが発生する。 sc_bufferは毎回の書き込み時、イベントが発生する。 したがって、cntr1の値は最後は"1"となり、cntr2の値は"10"となる。 sc_bufferはsc_signalを継承している。したがって、扱い方はほぼ同じといってよい。 ただし、2つのチャネルを併用したモデルは混乱するもとなので、片方のチャネルに統一して使ったほうがよい。 ただ、実際の設計では理想的にいかないかもしれないが。 sc_clockは何チャネル？ sc_clockはどうなのだろう？ sc_signal bool 型を継承しているので、一応sc_prim_channelを継承していることになるのでプリミティブ？でも、クロックを供給しているから、やっぱり階層チャネルの分類になるんだろうか？ ポート、階層、SC_METHOD、SC_THREAD等はないので、やはりプリミティブとみてよいのかも。 階層チャネル たとえば、バスプロトコルを設計するときに、複数のターゲッタを調停するためのアービタを設けたりする。そういったときに、チャネルにプロセスを持たせてアービタを実装する方法がある。 このとき、プロセスを持つチャネルのことを階層チャネルと呼ぶ。 階層チャネルはSystemCライブラリでは提供されていない？ので、ユーザが各自で設計することになる。 チャネルのクラスを定義するには sc_channel を継承する。 sc_channelについて チャネルはsc_channelを継承する。 sc_channelはsc_module.hの544行目に以下のように記述されている。 typedef sc_module sc_channel; つまり、「sc_module = sc_channel」であるためチャネルはモジュールと同じ扱いができる。 違いは、モジュールは自らが動作する。 それに対してチャネルはモジュールからのアクセスを受けることで動作する。 チャンネルはインタフェースを実装する。 まとめ チャネルを理解するためには次の内容が区別できているかが重要になる。 チャネル インターフェース ポート ここでは、インタフェースとポートにはほとんど触れなかったが。。。
https://w.atwiki.jp/bambooflow/pages/118.html
SystemCの参考ページ Open SystemC Initiative(OSCI) the North American SystemC User's Group(NASCUG) 参考にしている本 基礎から学ぶSystemC SystemCのおおよそ理解することに役立った。 C++を理解している人には良いかもしれない。 SystemCを使ったハードウェア設計―システム・レベル・モデリングからビヘイビア合成まで (Design Wave Advance) 動作合成向きのSystemC記述を中心に書かれている。 動作合成を勉強したい人にはよいかもしれない。 よくわかるSystemCによるシステムデザイン入門 内容は易しい。 RTL設計者でSystemCを始める人には良いかもしれない。 TLM設計についてはあまりふれていない。
https://w.atwiki.jp/systemc/pages/14.html
g++-4でのTLM-2.0のインストール OSCIのホームページからダウンロードしてきたTLM-2.0.1.tgzを展開する。 tar xvfz TLM-2.0.1.tgz 展開されたTLM-2009/07-15ディレクトリへ移動する。 cd TLM-2009-07-15 自分の環境に合わせて環境変数を設定する。 export TLM_HOME=/usr/local/src/TLM-2009-07-15 export SYSTEMC_HOME=/usr/local/systemc-2.2 export TARGET_ARCH=linux systemc-2.2/include/sysc/packages/boost/bind/placeholders.hppの28行目を #if defined(__BORLANDC__) から #if defined(__BORLANDC__) || defined(__GNUC__) に変更する。 /usr/local/systemc-2.2/include/sysc/datatypes/bit/sc_lv_base.hの306行目と307行目を return sc_logic_value_t( m_data[wi] bi SC_DIGIT_ONE | m_ctrl[wi] bi 1 SC_DIGIT_TWO ); から return sc_logic_value_t( (m_data[wi] bi SC_DIGIT_ONE) | (m_ctrl[wi] bi 1 SC_DIGIT_TWO) ); に変更する。 unit_test/tlm/build-unixディレクトリへ移動する。 cd unit_test/tlm/build-unix コンパイルを行う。 make run サンプルを実行する場合は、examples/tlm/build-unixディレクトリへ移動しmakeを実行する。 cd examples/tlm/build-unix make run unixの部分は、各自の環境に合わせて適切なものを選ぶ。 2010-07-22 23 24 26 (Thu)